Cream of the Crop 25/Cream of the Crop 25.iso/utility/ffe101.zip/GRAPH.SWG/0017_PNG.pas

Pascal/Delphi Source File | 1996-09-04 | 48KB | 1,059 lines

--------I-PNG-M-----------------------------

"excerpted from the PNG (Portable Network Graphics) specification, tenth
draft."

The PNG format (pronounced PiNG) was the replacement the Internet found,
after  the GIF format/CompuServe/LZW compression-patent  stuff. PNG is a
lossless  image-  compression  format,  which  allows  a  large range of
applications.  The  PNG  format  is in  the  public  domain,  the latest
versions  of the standard and related information can always be found at
the  PNG FTP archive site, ftp.uu.net:/graphics/png/. The maintainers of
the    PNG    specification    can   be    contacted    by   e-mail   at
[e-mail].

The  PNG format uses Motorola byte order, scanlines always begin on byte
boundaries. When pixels are less than 8 bits deep, if the scanline width
is  not  evenly  divisible  by the number  of  pixels  per byte then the
low-order  bits  in  the  last byte  of  each  scanline  are wasted. The
contents  of  the  padding  bits added to  fill  out  the last byte of a
scanline are unspecified.

An additional "filter" byte is added to the beginning of every scanline,
as  described in detail below. The filter byte is not considered part of
the  image  data,  but  it is included  in  the  data stream sent to the
compression step.

PNG  allows  the image data to be  filtered before it is compressed. The
purpose  of filtering is to improve the compressibility of the data. The
filter step itself does not reduce the size of the data. All PNG filters
are strictly lossless.

PNG  defines several different filter algorithms, including "none" which
indicates  no  filtering.  The filter  algorithm  is  specified for each
scanline  by a filter type byte  which precedes the filtered scanline in
the  precompression  data  stream.  An  intelligent  encoder  may switch
filters  from  one scanline to the  next.  The method for choosing which
filter to employ is up to the encoder.

A  PNG  image  can be stored  in  interlaced  order to allow progressive
display.  The  purpose of this feature is  to  allow images to "fade in"
when  they are being displayed  on-the-fly. Interlacing slightly expands
the  file  size on average, but it  gives  the user a meaningful display
much  more  rapidly. Note that decoders are  required to be able to read
interlaced  images,  whether  or not  they  actually perform progressive
display.

With  interlace  type  0, pixels are  stored  sequentially  from left to
right, and scanlines sequentially from top to bottom (no interlacing).

Interlace  type  1, known as Adam7  after  its author, Adam M. Costello,
consists  of seven distinct passes over the image. Each pass transmits a
subset  of  the  pixels in the image.  The  pass  in which each pixel is
transmitted  is defined by replicating the following 8-by-8 pattern over
the entire image, starting at the upper left corner:

1 6 4 6 2 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
3 6 4 6 3 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7

Within  each  pass,  the selected pixels  are  transmitted left to right
within  a  scanline,  and selected  scanlines  sequentially  from top to
bottom. For example, pass 2 contains pixels 4, 12, 20, etc. of scanlines
0,  8, 16, etc. (numbering from 0,0  at the upper left corner). The last
pass contains the entirety of scanlines 1, 3, 5, etc.

The data within each pass is laid out as though it were a complete image
of the appropriate dimensions. For example, if the complete image is 8x8
pixels,  then  pass  3  will contain  a  single  scanline containing two
pixels.  When  pixels are less than 8  bits  deep, each such scanline is
padded to fill an integral number of bytes (see Image layout). Filtering
is  done on this reduced image in the  usual way, and a filter type byte
is  transmitted  before each of  its  scanlines (see Filter Algorithms).
Notice  that the transmission order is defined so that all the scanlines
transmitted  in  a  pass will have the  same  number  of pixels; this is
necessary for proper application of some of the filters.

Caution:  If  the image contains fewer  than  five columns or fewer than
five  rows,  some  passes will be  entirely  empty.  Encoder and decoder
authors  must  be careful to handle  this case correctly. In particular,
filter  bytes  are  only associated  with  nonempty scanlines; no filter
bytes are present in an empty pass.

A  PNG file consists of a PNG  signature followed by a series of chunks.
This  chapter defines the signature and  the basic properties of chunks.
Individual chunk types are discussed in the next chapter.


PNG Header
OFFSET              Count TYPE   Description
0000h                   8 char   ID=89h,'PNG',13,10,26,10

Chunk layout
OFFSET              Count TYPE   Description
0000h                   1 dword  Number of data bytes after this header.
0004h                   4 char   Chunk type.
                                 A 4-byte chunk type code. For convenience in
                                 description and in examining PNG files, type
                                 codes are restricted to consist of uppercase
                                 and lowercase ASCII letters (A-Z, a-z).
                                 However, encoders and decoders should treat the
                                 codes as fixed binary values, not character
                                 strings. For example, it would not be correct
                                 to represent the type code IDAT by the EBCDIC
                                 equivalents of those letters.
????h                   ? byte   Data
????h                   1 dword  CRC calculated on the preceding bytes in that
                                 chunk, including the chunk type code and chunk
                                 data fields, but not including the length
                                 field. The CRC is always present, even for
                                 empty chunks such as IEND. The CRC algorithm
                                 is specified below.

Chunk naming conventions
========================

Chunk type codes are assigned in such a way that a decoder can determine
some  properties of a chunk even if it does not recognize the type code.
These  rules  are intended to allow  safe, flexible extension of the PNG
format, by allowing a decoder to decide what to do when it encounters an
unknown  chunk.  The  naming rules are  not  normally of interest when a
decoder does recognize the chunk's type.

Four  bits  of the type code, namely bit  5 (value 32) of each byte, are
used to convey chunk properties. This choice means that a human can read
off the assigned properties according to whether each letter of the type
code  is  uppercase  (bit 5 is 0)  or  lowercase  (bit 5 is 1). However,
decoders  should test the properties of  an unknown chunk by numerically
testing  the specified bits; testing whether a character is uppercase or
lowercase  is inefficient, and even  incorrect if a locale-specific case
definition is used.

It  is also worth noting that the  property bits are an inherent part of
the  chunk name, and hence are fixed  for any chunk type. Thus, TEXT and
Text   are  completely  unrelated  chunk  type  codes.  Decoders  should
recognize  codes by simple four-byte literal comparison; it is incorrect
to perform case conversion on type codes.

The semantics of the property bits are:

First Byte: 0 (uppercase) = critical, 1 (lowercase) = ancillary
   Chunks which are not strictly necessary in order to meaningfully
   display the contents of the file are known as "ancillary" chunks.
   Decoders encountering an unknown chunk in which the
   ancillary bit is 1 may safely ignore the chunk and proceed to
   display the image. The time chunk (tIME) is an example of an
   ancillary chunk.

   Chunks which are critical to the successful display of the file's
   contents are called "critical" chunks. Decoders encountering an
   unknown chunk in which the ancillary bit is 0 must indicate to
   the user that the image contains information they cannot safely
   interpret. The image header chunk (IHDR) is an example of a
   critical chunk.

Second Byte: 0 (uppercase) = public, 1 (lowercase) = private
   If the chunk is public (part of this specification or a later edition
   of this specification), its second letter is uppercase. If your
   application requires proprietary chunks, and you have no interest
   in seeing the software of other vendors recognize them, use a
   lowercase second letter in the chunk name. Such names will
   never be assigned in the official specification. Note that there is
   no need for software to test this property bit; it simply ensures
   that private and public chunk names will not conflict.

Third Byte: reserved, must be 0 (uppercase) always
   The significance of the case of the third letter of the chunk name
   is reserved for possible future expansion. At the present time all
   chunk names must have uppercase third letters.

Fourth Byte: 0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy
This  property bit is not of interest to pure decoders, but it is needed
by PNG editors (programs that modify a PNG file).

If  a  chunk's  safe-to-copy  bit is 1,  the  chunk  may  be copied to a
modified PNG file whether or not the software recognizes the chunk type,
and regardless of the extent of the file modifications.

If  a chunk's safe-to-copy bit is 0, it indicates that the chunk depends
on  the  image  data. If the program  has  made  any changes to critical
chunks,  including  addition, modification,  deletion,  or reordering of
critical  chunks, then unrecognized unsafe chunks  must not be copied to
the  output  PNG  file. (Of course,  if  the  program does recognize the
chunk, it may choose to output an appropriately modified version.)

A PNG editor is always allowed to copy all unrecognized chunks if it has
only  added, deleted, or modified ancillary chunks. This implies that it
is  not  permissible  to  make ancillary  chunks  that  depend  on other
ancillary chunks.

PNG  editors that do not recognize a critical chunk must report an error
and refuse to process that PNG file at all. The safe/unsafe mechanism is
intended for use with ancillary chunks. The safe-to-copy bit will always
be 0 for critical chunks.

For  example,  the hypothetical chunk type  name "bLOb" has the property
bits:

    bLOb  <-- 32 bit Chunk Name represented in ASCII form
    ||||
    |||'- Safe to copy bit is 1 (lower case letter; bit 5 of byte is 1)
    ||'-- Reserved bit is 0     (upper case letter; bit 5 of byte is 0)
    |'--- Private bit is 0      (upper case letter; bit 5 of byte is 0)
    '---- Ancillary bit is 1    (lower case letter; bit 5 of byte is 1)

Therefore,  this  name  represents  an  ancillary,  public, safe-to-copy
chunk.

See Rationale: Chunk naming conventions.

CRC algorithm
=============

Chunk  CRCs are calculated using standard  CRC methods with pre and post
conditioning. The CRC polynomial employed is as follows:

x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1

The  32-bit  CRC register is initialized to  all  1's, and then the data
from  each  byte is processed from the  least significant bit (1) to the
most  significant bit (128). After all the data bytes are processed, the
CRC  register is inverted (its ones  complement is taken). This value is
transmitted  (stored  in  the  file)  MSB  first.  For  the  purpose  of
separating  into  bytes and ordering, the  least  significant bit of the
32-bit CRC is defined to be the coefficient of the x^31 term.

Practical calculation of the CRC always employs a precalculated table to
greatly accelerate the computation. See Appendix: Sample CRC Code.

4. Chunk Specifications
=======================

This chapter defines the standard types of PNG chunks.

Critical Chunks
===============

All implementations must understand and successfully render the standard
critical  chunks.  A valid PNG image must  contain an IHDR chunk, one or
more IDAT chunks, and an IEND chunk.

IHDR Image Header This chunk must appear FIRST. Its contents are:

   Width:            4 bytes
   Height:           4 bytes
   Bit depth:        1 byte
   Color type:       1 byte
   Compression type: 1 byte
   Filter type:      1 byte
   Interlace type:   1 byte

Width  and  height give the image  dimensions in pixels. They are 4-byte
integers.  Zero is an invalid value. The maximum for each is (2^31)-1 in
order  to  accommodate  languages which  have  difficulty  with unsigned
4-byte values.

Bit  depth is a single-byte integer giving  the number of bits per pixel
(for palette images) or per sample (for grayscale and truecolor images).
Valid values are 1, 2, 4, 8, and 16, although not all values are allowed
for all color types.

Color type is a single-byte integer that describes the interpretation of
the  image  data.  Color  type values  represent  sums  of the following
values: 1 (palette used), 2 (color used), and 4 (full alpha used). Valid
values are 0, 2, 3, 4, and 6.

Bit  depth restrictions for each color type are imposed both to simplify
implementations  and  to  prohibit  certain  combinations  that  do  not
compress  well in practice. Decoders must support all legal combinations
of  bit  depth  and color type. (Note  that  bit depths of 16 are easily
supported  on  8-bit display hardware  by dropping the least significant
byte.) The allowed combinations are:

   Color    Allowed    Interpretation
   Type    Bit Depths

   0       1,2,4,8,16  Each pixel value is a grayscale level.

   2       8,16        Each pixel value is an R,G,B series.

   3       1,2,4,8     Each pixel value is a palette index;
                       a PLTE chunk must appear.

   4       8,16        Each pixel value is a grayscale level,
                       followed by an alpha channel level.

   6       8,16        Each pixel value is an R,G,B series,
                       followed by an alpha channel level.

Compression type is a single-byte integer that indicates the method used
to  compress  the  image  data.  At  present,  only  compression  type 0
(deflate/inflate  compression with a 32K sliding window) is defined. All
standard PNG images must be compressed with this scheme. The compression
type  code  is  provided for  possible  future  expansion or proprietary
variants.  Decoders must check this byte and report an error if it holds
an unrecognized code. See Deflate/Inflate Compression for details.

Filter  type  is a single-byte  integer that indicates the preprocessing
method  applied  to the image data  before compression. At present, only
filter  type  0  (adaptive filtering with  five  basic  filter types) is
defined.  As  with the compression type  code,  decoders must check this
byte  and  report an error if it  holds an unrecognized code. See Filter
Algorithms for details.

Interlace  type is a single-byte integer that indicates the transmission
order  of  the  pixel  data. Two  values  are  currently  defined: 0 (no
interlace)  or  1  (Adam7  interlace).  See  Interlaced  data  order for
details.

PLTE Palette
This  chunk's  contents  are  from  1  to  256  palette  entries, each a
three-byte series of the form:

   red:   1 byte (0 = black, 255 = red)
   green: 1 byte (0 = black, 255 = green)
   blue:  1 byte (0 = black, 255 = blue)

The  number  of  entries is determined  from  the  chunk length. A chunk
length not divisible by 3 is an error.

This  chunk must appear for color type 3, and may appear for color types
2  and  6.  If this chunk does  appear,  it  must precede the first IDAT
chunk. There cannot be more than one PLTE chunk.

For  color type 3 (palette data), the  PLTE chunk is required. The first
entry  in PLTE is referenced by pixel value 0, the second by pixel value
1, etc. The number of palette entries must not exceed the range that can
be  represented by the bit depth (for example,  2^4 = 16 for a bit depth
of  4). It is permissible to have fewer entries than the bit depth would
allow.  In  that case, any out-of-range  pixel  value found in the image
data is an error.

For  color  types  2 and 6 (truecolor),  the  PLTE chunk is optional. If
present,  it provides a recommended set of from 1 to 256 colors to which
the  truecolor  image  may  be quantized  if  the  viewer cannot display
truecolor  directly.  If PLTE is not  present, such a viewer must select
colors  on its own, but it is often  preferable for this to be done once
by the encoder.

Note  that the palette uses 8 bits  (1 byte) per value regardless of the
image bit depth specification. In particular, the palette is 8 bits deep
even when it is a suggested quantization of a 16-bit truecolor image.

IDAT Image Data
This  chunk  contains the actual image  data. To create this data, begin
with  image  scanlines represented as  described under Image layout; the
layout  and  total size of this raw  data are determinable from the IHDR
fields.  Then  filter the image data  according  to the filtering method
specified  by the IHDR chunk. (Note that  with filter method 0, the only
one  currently  defined, this implies prepending  a  filter type byte to
each   scanline.)   Finally,  compress  the   filtered  data  using  the
compression  method specified by the IHDR chunk. The IDAT chunk contains
the  output  datastream of the compression  algorithm. To read the image
data, reverse this process.

There may be multiple IDAT chunks; if so, they must appear consecutively
with  no other intervening chunks. The compressed datastream is then the
concatenation  of  the contents of all  the IDAT chunks. The encoder may
divide  the  compressed  data  stream into  IDAT  chunks  as  it wishes.
(Multiple  IDAT chunks are allowed so that  encoders can work in a fixed
amount  of  memory;  typically  the chunk  size  will  correspond to the
encoder's  buffer  size.) It is important  to  emphasize that IDAT chunk
boundaries  have no semantic significance and can appear at any point in
the  compressed datastream. A PNG file in which each IDAT chunk contains
only  one data byte is legal,  though remarkably wasteful of space. (For
that  matter,  zero-length  IDAT  chunks  are  legal,  though  even more
wasteful.)

See Filter Algorithms and Deflate/Inflate Compression for details.

IEND Image Trailer
This  chunk  must appear LAST. It marks  the end of the PNG data stream.
The chunk's data field is empty.

Ancillary Chunks
================

All  ancillary chunks are optional, in  the sense that encoders need not
write   them  and  decoders  may  ignore  them.  However,  encoders  are
encouraged  to write the standard  ancillary chunks when the information
is available, and decoders are encouraged to interpret these chunks when
appropriate and feasible.

The  standard ancillary chunks are listed in alphabetical order. This is
not necessarily the order in which they would appear in a file.

bKGD Background Color
This  chunk specifies a default background color against which the image
may be presented. Note that viewers are not bound to honor this chunk; a
viewer may choose to use a different background color.

   For color type 3 (palette), the bKGD chunk contains:

   palette index: 1 byte

The value is the palette index of the color to be used as background.

For  color  types  0  and 4  (grayscale,  with  or  without alpha), bKGD
contains:

   gray:  2 bytes, range 0 .. (2^bitdepth) - 1

(For  consistency, 2 bytes are used  regardless of the image bit depth.)
The value is the gray level to be used as background.

For color types 2 and 6 (RGB, with or without alpha), bKGD contains:

   red:   2 bytes, range 0 .. (2^bitdepth) - 1
   green: 2 bytes, range 0 .. (2^bitdepth) - 1
   blue:  2 bytes, range 0 .. (2^bitdepth) - 1

(For  consistency,  2 bytes per sample  are used regardless of the image
bit depth.) This is the RGB color to be used as background.

When present, the bKGD chunk must precede the first IDAT chunk, and must
follow the PLTE chunk, if any.

   See Recommendations for Decoders: Background color.

cHRM Primary Chromaticities and White Point
Applications that need precise specification of colors in a PNG file may
use this chunk to specify the chromaticities of the red, green, and blue
primaries  used  in  the image, and  the  referenced  white point. These
values  are  based on the 1931  CIE  (International Color Committee) XYZ
color  space. Only the chromaticities (x and y) are specified. The chunk
layout is:

   White Point x: 4 bytes
   White Point y: 4 bytes
   Red x:         4 bytes
   Red y:         4 bytes
   Green x:       4 bytes
   Green y:       4 bytes
   Blue x:        4 bytes
   Blue y:        4 bytes

Each  value is encoded as a  4-byte unsigned integer, representing the x
or y value times 100000.

If  the cHRM chunk appears, it must precede the first IDAT chunk, and it
must also precede the PLTE chunk if present.

gAMA Gamma Correction
The  gamma  correction  chunk  specifies the  gamma  of  the  camera (or
simulated  camera)  that produced the image,  and  thus the gamma of the
image with respect to the original scene. Note that this is not the same
as  the  gamma  of  the display  device  that  will  reproduce the image
correctly.

   The chunk's contents are:

   Image gamma value: 4 bytes

A value of 100000 represents a gamma of 1.0, a value of 45000 a gamma of
0.45,  and so on (divide by 100000.0). Values around 1.0 and around 0.45
are common in practice.

If  the  encoder  does not know the  gamma  value, it should not write a
gamma  chunk;  the  absence  of a  gamma  chunk  indicates  the gamma is
unknown.

If  the gAMA chunk appears, it must precede the first IDAT chunk, and it
must also precede the PLTE chunk if present.

See  Gamma  correction,  Recommendations  for  Encoders:  Encoder  gamma
handling, and Recommendations for Decoders: Decoder gamma handling.

hIST Image Histogram
The  histogram chunk gives the approximate usage frequency of each color
in  the color palette. A histogram chunk  may appear only when a palette
chunk appears. If a viewer is unable to provide all the colors listed in
the  palette, the histogram may help it decide how to choose a subset of
the colors for display.

This chunk's contents are a series of 2-byte (16 bit) unsigned integers.
There  must be exactly one entry for  each entry in the PLTE chunk. Each
entry  is proportional to the fraction of  pixels in the image that have
that palette index; the exact scale factor is chosen by the encoder.

Histogram  entries are approximate, with the exception that a zero entry
specifies that the corresponding palette entry is not used at all in the
image. It is required that a histogram entry be nonzero if there are any
pixels of that color.

When  the palette is a suggested  quantization of a truecolor image, the
histogram  is necessarily approximate, since a decoder may map pixels to
palette  entries  differently than the  encoder  did. In this situation,
zero entries should not appear.

The  hIST  chunk,  if it appears, must  follow  the PLTE chunk, and must
precede the first IDAT chunk.

See  Rationale:  Palette histograms,  and  Recommendations for Decoders:
Palette histogram usage.

pHYs Physical Pixel Dimensions
This  chunk specifies the intended resolution  for display of the image.
The chunk's contents are:

   4 bytes: pixels per unit, X axis (unsigned integer)
   4 bytes: pixels per unit, Y axis (unsigned integer)
   1 byte: unit specifier

   The following values are legal for the unit specifier:

   0: unit is unknown (pHYs defines pixel aspect ratio only)
   1: unit is the meter

   Conversion note: one inch is equal to exactly 0.0254 meters.

If this ancillary chunk is not present, pixels are assumed to be square,
and the physical size of each pixel is unknown.

   If present, this chunk must precede the first IDAT chunk.

   See Recommendations for Decoders: Pixel dimensions.

sBIT Significant Bits
To  simplify decoders, PNG specifies that  only certain bit depth values
be  used, and further specifies that pixel  values must be scaled to the
full range of possible values at that bit depth. However, the sBIT chunk
is  provided in order to store  the original number of significant bits,
since this information may be of use to some decoders. We recommend that
an  encoder  emit  an  sBIT chunk if  it  has  converted the data from a
different bit depth.

For  color  type 0 (grayscale), the  sBIT  chunk contains a single byte,
indicating the number of bits which were significant in the source data.

For  color type 2 (RGB truecolor),  the sBIT chunk contains three bytes,
indicating  the number of bits which were significant in the source data
for the red, green, and blue channels, respectively.

For  color type 3 (palette color),  the sBIT chunk contains three bytes,
indicating  the number of bits which were significant in the source data
for  the  red,  green,  and  blue  components  of  the  palette entries,
respectively.

For color type 4 (grayscale with alpha channel), the sBIT chunk contains
two  bytes, indicating the number of  bits which were significant in the
source grayscale data and the source alpha channel data, respectively.

For  color  type  6 (RGB truecolor  with  alpha channel), the sBIT chunk
contains   four  bytes,  indicating  the   number  of  bits  which  were
significant  in  the  source  data for  the  red,  green, blue and alpha
channels, respectively.

Note  that sBIT does not have any implications for the interpretation of
the  stored image: the bit depth indicated by IHDR is the correct depth.
sBIT is only an indication of the history of the image. However, an sBIT
chunk  showing  a bit depth less than  the IHDR bit depth does mean that
not  all  possible color values occur in  the image; this fact may be of
use to some decoders.

If  the sBIT chunk appears, it must precede the first IDAT chunk, and it
must also precede the PLTE chunk if present.

tEXt Textual Data
Any textual information that the encoder wishes to record with the image
is  stored in tEXt chunks. Each tEXt chunk contains a keyword and a text
string, in the format:

   Keyword:        n bytes (character string)
   Null separator: 1 byte
   Text:           n bytes (character string)

The  keyword  and  text  string  are  separated  by  a  zero  byte (null
character).  Neither the keyword nor the  text string may contain a null
character.  Note that the text string is not null-terminated (the length
of  the  chunk  is  sufficient information  to  locate  the ending). The
keyword must be at least one character and less than 80 characters long.
The  text string may be of any length  from zero bytes up to the maximum
permissible chunk size.

Any  number  of tEXt chunks may appear,  and more than one with the same
keyword is permissible.

The  keyword  indicates the type of  information represented by the text
string.  The following keywords are predefined  and should be used where
appropriate:

   Title            Short (one line) title or caption for image
   Author           Name of image's creator
   Copyright        Copyright notice
   Description      Description of image (possibly long)
   Software         Software used to create the image
   Disclaimer       Legal disclaimer
   Warning          Warning of nature of content
   Source           Device used to create the image
   Comment          Miscellaneous comment; conversion from GIF comment

Other  keywords, containing any sequence  of printable characters in the
character  set, may be invented for  other purposes. Keywords of general
interest   may   be   registered  with   the   maintainers  of  the  PNG
specification.

Keywords must be spelled exactly as registered, so that decoders may use
simple  literal  comparisons  when looking  for  particular keywords. In
particular, keywords are considered case-sensitive.

Both  keyword  and  text  are interpreted  according  to  the ISO 8859-1
(Latin-1)   character  set.  Newlines  in  the  text  string  should  be
represented  by  a single linefeed character  (decimal 10); use of other
ASCII control characters is discouraged.

See   Recommendations   for   Encoders:   Text   chunk   processing  and
Recommendations for Decoders: Text chunk processing.

tIME Image Last-Modification Time
This  chunk gives the time of the  last image modification (not the time
of initial image creation). The chunk contents are:

   2 bytes: Year (complete; for example, 1995, not 95)
   1 byte: Month (1-12)
   1 byte: Day (1-31)
   1 byte: Hour (0-23)
   1 byte: Minute (0-59)
   1 byte: Second (0-60)    (yes, 60, for leap seconds; not 61, a common error)

Universal  Time  (UTC, also called GMT)  should be specified rather than
local time.

tRNS Transparency
Transparency  is  an  alternative to  the  full  alpha channel. Although
transparency  is  not as elegant as  the full alpha channel, it requires
less storage space and is sufficient for many common cases.

For  color type 3 (palette), this chunk's contents are a series of alpha
channel bytes, corresponding to entries in the PLTE chunk:

   Alpha for palette index 0:  1 byte
   Alpha for palette index 1:  1 byte
   etc.

Each entry indicates that pixels of that palette index should be treated
as  having  the  specified  alpha  value.  Alpha  values  have  the same
interpretation   as  in  an  8-bit  full   alpha  channel:  0  is  fully
transparent,  255  is fully opaque, regardless  of  image bit depth. The
tRNS  chunk may contain fewer alpha channel bytes than there are palette
entries. In this case, the alpha channel value for all remaining palette
entries  is  assumed  to be 255. In  the  common case where only palette
index  0 need be made transparent, only a one-byte tRNS chunk is needed.
The  tRNS  chunk  may  not contain  more  bytes  than  there are palette
entries.

For  color  type  0 (grayscale), the  tRNS  chunk contains a single gray
level value, stored in the format

   gray:  2 bytes, range 0 .. (2^bitdepth) - 1

(For  consistency, 2 bytes are used  regardless of the image bit depth.)
Pixels  of  the  specified gray level  are  to be treated as transparent
(equivalent  to  alpha value 0); all other  pixels  are to be treated as
fully opaque (alpha value (2^bitdepth)-1).

For  color  type  2 (RGB), the tRNS  chunk  contains  a single RGB color
value, stored in the format

   red:   2 bytes, range 0 .. (2^bitdepth) - 1
   green: 2 bytes, range 0 .. (2^bitdepth) - 1
   blue:  2 bytes, range 0 .. (2^bitdepth) - 1

(For  consistency,  2 bytes per sample  are used regardless of the image
bit  depth.)  Pixels of the specified color  value  are to be treated as
transparent  (equivalent  to alpha value 0);  all other pixels are to be
treated as fully opaque (alpha value (2^bitdepth)-1).

tRNS  is prohibited for color types 4  and 6, since a full alpha channel
is already present in those cases.

Note: when dealing with 16-bit grayscale or RGB data, it is important to
compare  both bytes of the sample values to determine whether a pixel is
transparent.  Although  decoders  may  drop  the  low-order  byte of the
samples  for display, this must not occur  until after the data has been
tested  for transparency. For example, if  the grayscale level 0x0001 is
specified  to be transparent, it would  be incorrect to compare only the
high-order byte and decide that 0x0002 is also transparent.

When present, the tRNS chunk must precede the first IDAT chunk, and must
follow the PLTE chunk, if any.

zTXt Compressed Textual Data
A  zTXt  chunk contains textual data,  just  as tEXt does; however, zTXt
takes advantage of compression.

A  zTXt chunk begins with an  uncompressed Latin-1 keyword followed by a
null  (0) character, just as in the  tEXt chunk. The next byte after the
null  contains  a  compression type byte,  for  which the only presently
legitimate    value   is   zero   (deflate/inflate   compression).   The
compression-type  byte  is  followed by  a  compressed data stream which
makes  up the remainder of the  chunk. Decompression of this data stream
yields  Latin-1  text which is equivalent to  the  text stored in a tEXt
chunk.

Any  number of zTXt and tEXt chunks may appear in the same file. See the
preceding  definition of the tEXt chunk  for the predefined keywords and
the exact format of the text.

See  Deflate/Inflate  Compression,  Recommendations  for  Encoders: Text
chunk   processing,   and  Recommendations   for  Decoders:  Text  chunk
processing.

Summary of Standard Chunks
==========================

This table summarizes some properties of the standard chunk types.

Critical chunks (must appear in this order, except PLTE is optional):

        Name  Multiple  Ordering constraints
                OK?

        IHDR    No      Must be first
        PLTE    No      Before IDAT
        IDAT    Yes     Multiple IDATs must be consecutive
        IEND    No      Must be last

Ancillary chunks (need not appear in this order):

        Name  Multiple  Ordering constraints
                OK?

        cHRM    No      Before PLTE and IDAT
        gAMA    No      Before PLTE and IDAT
        sBIT    No      Before PLTE and IDAT
        bKGD    No      After PLTE; before IDAT
        hIST    No      After PLTE; before IDAT
        tRNS    No      After PLTE; before IDAT
        pHYs    No      Before IDAT
        tIME    No      None
        tEXt    Yes     None
        zTXt    Yes     None

Standard keywords for tEXt and zTXt chunks:

Title            Short (one line) title or caption for image
Author           Name of image's creator
Copyright        Copyright notice
Description      Description of image (possibly long)
Software         Software used to create the image
Disclaimer       Legal disclaimer
Warning          Warning of nature of content
Source           Device used to create the image
Comment          Miscellaneous comment; conversion from GIF comment

Additional Chunk Types
======================

Additional  public  PNG  chunk types are  defined  in  the document "PNG
Special-Purpose     Public    Chunks",    available    by    FTP    from
ftp.uu.net:/graphics/png/         or         via         WWW        from
http://sunsite.unc.edu/boutell/pngextensions.html.

5. Deflate/Inflate Compression
==============================

PNG  compression  type 0 (the  only compression method presently defined
for  PNG)  specifies  deflate/inflate  compression  with  a  32K window.
Deflate  compression is an LZ77 derivative  used in zip, gzip, pkzip and
related  programs.  Extensive  research  has  been  done  supporting its
patent-free status. Portable C implementations are freely available.

Documentation  and  C code for deflate  are  available from the Info-Zip
archives at ftp.uu.net:/pub/archiving/zip/.

Deflate-compressed  datastreams  within  PNG are  stored  in  the "zlib"
format, which has the structure:

Compression method/flags code: 1 byte
Additional flags/check bits:   1 byte
Compressed data blocks:        n bytes
Checksum:                      4 bytes

Further  details on this format may  be found in the zlib specification.
At  this  writing,  the  zlib  specification  is  at  draft  3.1, and is
available from ftp.uu.net:/pub/archiving/zip/doc/zlib-3.1.doc.

For  PNG compression type 0, the zlib compression method/flags code must
specify method code 8 ("deflate" compression) and an LZ77 window size of
not more than 32K.

The  checksum stored at the end of  the zlib datastream is calculated on
the  uncompressed  data  represented by  the  datastream.  Note that the
algorithm used is not the same as the CRC calculation used for PNG chunk
checksums.  Verifying  the chunk CRCs  provides adequate confidence that
the PNG file has been transmitted undamaged. The zlib checksum is useful
mainly  as  a  crosscheck that the  deflate  and  inflate algorithms are
implemented correctly.

In  a PNG file, the concatenation of the contents of all the IDAT chunks
makes   up  a  zlib  datastream  as  specified  above.  This  datastream
decompresses  to  filtered  image data  as  described  elsewhere in this
document.

It is important to emphasize that the boundaries between IDAT chunks are
arbitrary  and  may fall anywhere in  the  zlib datastream. There is not
necessarily  any  correlation between IDAT  chunk boundaries and deflate
block  boundaries or any other feature of the zlib data. For example, it
is  entirely  possible  for the terminating  zlib  checksum  to be split
across IDAT chunks.

PNG  also  uses  zlib datastreams in zTXt  chunks.  In a zTXt chunk, the
remainder  of  the chunk following the  compression  type code byte is a
zlib  datastream as specified above. This datastream decompresses to the
user-readable  text  described by the  chunk's keyword. Unlike the image
data,  such  datastreams  are not split  across  chunks; each zTXt chunk
contains an independent zlib datastream.

6. Filter Algorithms
====================

This  chapter  describes  the pixel  filtering  algorithms  which may be
applied  in  advance of compression. The  purpose of these filters is to
prepare the image data for optimum compression.

PNG  defines  five basic filtering  algorithms,  which are given numeric
codes as follows:

Code    Name
0       None
1       Sub
2       Up
3       Average
4       Paeth

The    encoder   may   choose   which    algorithm   to   apply   on   a
scanline-by-scanline  basis.  In the image  data sent to the compression
step,  each  scanline is preceded by  a  filter type byte containing the
numeric code of the filter algorithm used for that scanline.

Filtering  algorithms are applied to bytes, not to pixels, regardless of
the  bit depth or color type of the image. The filtering algorithms work
on  the byte sequence formed by a  scanline that has been represented as
described under Image layout.

When  the  image  is interlaced, each  pass  of the interlace pattern is
treated as an independent image for filtering purposes. The filters work
on the byte sequences formed by the pixels actually transmitted during a
pass,  and the "previous scanline" is  the one previously transmitted in
the same pass, not the one adjacent in the complete image. Note that the
subimage  transmitted  in any one pass  is always rectangular, but is of
smaller  width  and/or height than the  complete image. Filtering is not
applied when this subimage is empty.

For  all  filters,  the  bytes "to the  left  of"  the  first pixel in a
scanline  must  be treated as being zero.  For filters that refer to the
prior  scanline,  the  entire prior scanline  must  be  treated as being
zeroes for the first scanline of an image (or of a pass of an interlaced
image).

To  reverse  the  effect of a filter,  the  decoder must use the decoded
values  of the prior pixel on the same line, the pixel immediately above
the  current pixel on the prior line, and  the pixel just to the left of
the  pixel  above.  This implies that  at  least one scanline's worth of
image  data must be stored by the decoder at all times. Even though some
filter types do not refer to the prior scanline, the decoder must always
store  each scanline as it is decoded, since the next scanline might use
a filter that refers to it.

PNG  imposes  no restriction on which filter  types may be applied to an
image.  However,  the filters are not  equally effective on all types of
data. See Recommendations for Encoders: Filter selection.

Filter type 0: None
===================

With the None filter, the scanline is transmitted unmodified; it is only
necessary to insert a filter type byte before the data.

Filter type 1: Sub
==================

The  Sub filter transmits the difference between each byte and the value
of the corresponding byte of the prior pixel.

To  compute the Sub filter, apply the  following formula to each byte of
each scanline:

  Sub(x) = Raw(x) - Raw(x-bpp)

where  x  ranges  from  zero to  the  number  of bytes representing that
scanline  minus  one,  Raw(x) refers to the  raw  data byte at that byte
position  in the scanline, and bpp is defined as the number of bytes per
complete pixel, rounding up to one. For example, for color type 2 with a
bit  depth  of  16,  bpp is equal  to  6  (three channels, two bytes per
channel);  for  color  type 0 with a bit  depth  of 2, bpp is equal to 1
(rounding  up); for color type 4 with a bit depth of 16, bpp is equal to
4 (two-byte grayscale value, plus two-byte alpha channel).

Note this computation is done for each byte, regardless of bit depth. In
a 16-bit image, MSBs are differenced from the preceding MSB and LSBs are
differenced  from  the  preceding LSB, because  of  the  way that bpp is
defined.

Unsigned  arithmetic  modulo  256 is used,  so  that both the inputs and
outputs fit into bytes. The sequence of Sub values is transmitted as the
filtered scanline.

For all x < 0, assume Raw(x) = 0.

To  reverse the effect of the Sub filter after decompression, output the
following value:

  Sub(x) + Raw(x-bpp)

(computed mod 256), where Raw refers to the bytes already decoded.

Filter type 2: Up
=================

The  Up  filter  is  just  like the  Sub  filter  except  that the pixel
immediately  above  the current pixel, rather  than just to its left, is
used as the predictor.

To  compute  the Up filter, apply the  following formula to each byte of
each scanline:

  Up(x) = Raw(x) - Prior(x)

where  x  ranges  from  zero to  the  number  of bytes representing that
scanline  minus  one,  Raw(x) refers to the  raw  data byte at that byte
position in the scanline, and Prior(x) refers to the unfiltered bytes of
the prior scanline.

Note  this  is  done for each  byte,  regardless  of bit depth. Unsigned
arithmetic  modulo 256 is used, so that  both the inputs and outputs fit
into  bytes.  The sequence of Up  values  is transmitted as the filtered
scanline.

On the first scanline of an image (or of a pass of an interlaced image),
assume Prior(x) = 0 for all x.

To  reverse the effect of the  Up filter after decompression, output the
following value:

  Up(x) + Prior(x)

(computed mod 256), where Prior refers to the decoded bytes of the
prior scanline.

Filter type 3: Average
======================

The  Average filter uses the average of the two neighboring pixels (left
and above) to predict the value of a pixel.

To  compute the Average filter, apply the following formula to each byte
of each scanline:

  Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/2)

where  x  ranges  from  zero to  the  number  of bytes representing that
scanline  minus  one,  Raw(x) refers to the  raw  data byte at that byte
position in the scanline, Prior(x) refers to the unfiltered bytes of the
prior scanline, and bpp is defined as for the Sub filter.

Note  this is done for each byte,  regardless of bit depth. The sequence
of Average values is transmitted as the filtered scanline.

The  subtraction  of the predicted value from  the raw byte must be done
modulo 256, so that both the inputs and outputs fit into bytes. However,
the  sum  Raw(x-bpp)+Prior(x) must be  formed without overflow (using at
least  nine-bit  arithmetic). floor() indicates  that  the result of the
division  is  rounded to the next  lower integer if fractional; in other
words, it is an integer division or right shift operation.

For  all x < 0, assume Raw(x) = 0. On the first scanline of an image (or
of a pass of an interlaced image), assume Prior(x) = 0 for all x.

To  reverse the effect of the Average filter after decompression, output
the following value:

  Average(x) + floor((Raw(x-bpp)+Prior(x))/2)

where  the result is computed mod  256, but the prediction is calculated
in  the  same  way  as for encoding.  Raw  refers  to  the bytes already
decoded, and Prior refers to the decoded bytes of the prior scanline.

Filter type 4: Paeth
====================

The  Paeth  filter  computes  a  simple  linear  function  of  the three
neighboring  pixels (left, above, upper left), then chooses as predictor
the  neighboring pixel closest to the  computed value. This technique is
taken from Alan W. Paeth's article "Image File Compression Made Easy" in
Graphics Gems II, James Arvo, editor, Academic Press, 1991.

To compute the Paeth filter, apply the following formula to each byte of
each scanline:

  Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp))

where  x  ranges  from  zero to  the  number  of bytes representing that
scanline  minus  one,  Raw(x) refers to the  raw  data byte at that byte
position in the scanline, Prior(x) refers to the unfiltered bytes of the
prior scanline, and bpp is defined as for the Sub filter.

Note  this  is  done for each  byte,  regardless  of bit depth. Unsigned
arithmetic  modulo 256 is used, so that  both the inputs and outputs fit
into  bytes. The sequence of Paeth values is transmitted as the filtered
scanline.

The PaethPredictor function is defined by the following pseudocode:

     function PaethPredictor (a, b, c)
     begin
          ; a = left, b = above, c = upper left
          p := a + b - c        ; initial estimate
          pa := abs(p - a)      ; distances to a, b, c
          pb := abs(p - b)
          pc := abs(p - c)
          ; return nearest of a,b,c,
          ; breaking ties in order a,b,c.
          if pa <= pb AND pa <= pc
          begin
               return a
          end
          if pb <= pc
          begin
               return b
          end
          return c
     end

The  calculations  within the PaethPredictor  function must be performed
exactly,  without overflow. Arithmetic modulo 256 is to be used only for
the  final step of subtracting the function result from the target pixel
value.

Note  that  the order in which ties are  broken is fixed and must not be
altered.  The tie break order is: pixel  to the left, pixel above, pixel
to  the  upper  left.  (This order  differs  from  that given in Paeth's
article.)

For all x < 0, assume Raw(x) = 0 and Prior(x) = 0. On the first scanline
of  an image (or of a pass of  an interlaced image), assume Prior(x) = 0
for all x.

To  reverse  the effect of the  Paeth filter after decompression, output
the following value:

  Paeth(x) + PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp))

(computed  mod 256), where Raw and Prior refer to bytes already decoded.
Exactly  the  same PaethPredictor function is  used  by both encoder and
decoder.

For more information, check out the above ftp sites.

EXTENSION:PNG
OCCURENCES:PC,UNIX,AMIGA
PROGRAMS:????
REFERENCE:The PNG Specification